Device configuration and management development system

ABSTRACT

A device configuration development system uses a common configuration and management database for the development of configuration and management data. A device management system for set of devices is provided from the common and management data for the management and configuration of a set of devices. Each device in the set of devices is also provided with a subset of management and configuration data related to the device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority under 35 U.S.C. § 365(c)and § 120 to International Application Number PCT/GB02/03338, filed Jul.23, 2002, published as WO 03/012635 A2, and under 35 U.S.C. § 119(a)-(d)or 365(b) to Great Britain Application Number 0118377.1, filed Jul. 27,2001, all of which are hereby incorporated by reference herein.

The present invention relates to the development and/or management ofconfiguration and management parameters for devices.

There is a need when developing devices for a management capability forthe devices to be generated. Thus a device developer must devote sometime to the task of providing management capabilities in a device. Thisis something that many developers dislike and can overlook. Theresponsibility usually falls to an administrator or manager to ensurethat a management function is provided in the device by requestingcertain management functions to be encoded in the device.

With the prevalent use of networked devices, the provision for bothlocal and remote management has become essential for the properfunctioning of a network. Networked devices can be used for a wide rangeof functions and it highly desirable to provide both local and centralmanagement.

In the prior art, the provision of both local and central management ofdevices is approached separately. A device developer is frequentlyrequired to provide certain management functions and does so byproviding software for the device which provides an interface to thedevice e.g. over the network. An administrator or manager then providesa central management capability separately. This means that there is afragmented approach to the management of the devices. There are twoseparate development groups, one providing local management and theother providing central management. This requires an increase in effortmaking it time consuming and expensive to create and maintain all thenecessary documentation. Further coordination between the groups can bedifficult and thus the maintenance of consistency and compatibilitybetween the two ends of the management can be difficult. Further,developers who are normally responsible for influencing device featuresoften do not understand the management requirements.

Thus in accordance with one aspect of the present invention, the presentinventors have developed and end to end management solution whichutilizes a common management data structure during the development,deployment, and use of managed devices. A common management model isused which can provide a common management interface.

One aspect of the present invention provides a device configurationsystem and method for developing and managing configuration andmanagement information for devices. The system enables developers todevelop configuration data and/or management data. Configuration and/ormanagement data is stored as device data that is stored in accordancewith a common management model. This enables the parameters and themanagement information to be managed. Parameters and management dataentered in the common model can be output in a software product as adevice management product which includes a parameters and managementdata for a set of devices. The device management product can thus beused to configure and manage a set of devices using the commonmanagement model. Each device has configuration and management datastored therein in accordance with the common management model. Thisprovides for both central management and for local management using thecommon management model. In this way end to end management is provided.

Another aspect of the present invention provides a device configurationdevelopment system for developing and/or managing configuration and/ormanagement information for devices. Device data structured in accordancewith the common model of parameters relating to the configuration and/ormanagement of the devices is stored. A developer interface allows asoftware developer to develop software for configuring and/or managingdevices and to store device data in accordance with a common model. Adevice configuration and/or management software product for configuringand managing a set of devices is built by reading stored data for a setof devices structured in accordance with the common model. Devicemanagement and control software is configured for controlling aprocessing apparatus in a device manager to configure and/or manage thedevices using the data for the devices included in the product and toprovide the data for a device to the device to allow a localconfiguration and/or management at the device. The device management andcontrol software can be included in the product or it can be alreadyinstalled in the device manager processing apparatus.

In one embodiment of the present invention, the software product isbuilt by reading and including in the software product the softwaredeveloped by the software developer for loading onto devices forconfiguring and managing the devices.

In a preferred embodiment, the devices comprise network devices and thecommon model is a model of parameters relating to the configuration andmanagement of the network devices which can be for example networkconfiguration parameters e.g. network protocol capabilities.

In one embodiment of the present invention, the common management modelcomprises a model of hardware characteristics, software characteristicsand relationships therebetween. This therefore provides a full pictureof the characteristics of the device for management purposes.

In one embodiment of the present the device data comprises configurationdata and meta data. The configuration data defines configurationparameters that can be set for the device. A configuration data can haveconfiguration values that can be set by the developer or be settable bya manager centrally or by an operator of the device The meta datacomprises management information for the configuration data and for thedevice.

In one embodiment the device data can include management data whichincludes interface information defining the configuration of a userinterface to the device data i.e. defining a management interface. Inthis way, the meta data can define a common interface for central andlocal management. In one embodiment, for networked devices, the commonuser interface preferably comprises a web interface provided by a webserver.

In one embodiment of the present invention, the device data can becopied to allow a developer to enter device data if the need arise bysimply copying device data for another device which most closelyresembles the new device to be developed and modifying the device dataas necessary.

In one embodiment of the present invention, the developer interfacemeans includes means for generating code stubs for managementfunctionality from the device data for combination with the softwareprovided by the software developer to control the device. Thus thiscapability provides encouragement for a developer to use the developmentsystem to enter the management data and the task of writing the code forthe management functionality is removed from the developer. It is onlynecessary for the developer to interface the code stubs into their codeby writing suitable interface code or ‘glue’.

In one embodiment of the present invention, documentation for eachdevice is stored. This can be stored as segments associated withrespective parameters in the common model. Documentation for a devicecan be generated automatically by inserting management information fromthe management model into the documentation. Thus as managementparameters are updated, the documentation is automatically updated. Thedocumentation can be stored as document segments with each segment beingassociated with a respective parameter and having management parametersassociated therewith. Thus documentation can be built up byincorporating management parameters into the documentation segments andaggregating the document segments to provide complete documentation forthe device.

Within the common model, it is possible for the configuration parametersto identify a configured device comprising configuration data which iscomplete for a device or a configuration profile that includes someconfiguration data that can be input to complete or modify theconfiguration data for a device. For example, a number of configurationparameters could be set to a default value that can be altered by a userin order to modify the configuration data to provide a device profile.Thus in this way configuration parameters for a device can compriseconfiguration parameters from a configuration profile and user inputconfiguration parameters. The configuration parameters from aconfiguration profile can be common to a large number of devices.

In accordance with another aspect, the present invention provides amanagement system or method for managing devices using the commonmanagement model. Data storage means stores management and configurationdata for each device for managing and configuring the device. Themanagement and configuration data is structured in accordance with thecommon management model i.e. in accordance with a common model ofparameters related to the functioning and management of the devices.Means of communicating with the devices is provided in each device. Alsothe devices are provided with a copy of the management and configurationdata for respective devices to provide for local management andconfiguration. Thus each device has a subset of the data in the commonmanagement model relevant for the management of the device. A devicemanagement means controls communications to and from the devices toprovide central configuration of the devices and receipt of managementdata from the devices.

Thus in accordance with this aspect of the present invention, a devicemanagement system can be provided by the device development environmentand the common management model can be used in both.

The device management system can, in one embodiment, provide the copy ofthe management and configuration data to each of the devices. In thisway the management system can provide the initial configuration for thedevices. This initial configuration can include the storage of codemodules for controlling the devices for sending to and storing at thedevices. The code module can be the same for the same type of devicethus providing for not only common hardware but also common software fordevices. The only difference between devices thus lies in theconfiguration and management data. This enables simple reconfigurationof devices by reconfiguration of their configuration and managementdata. No change of code is needed.

The configuration data defines configuration instances for devices. Alsothe configuration data can define a configuration profile for which someuser definable configuration data can be entered or modified. Thisenables a configuration profile to apply to a set of devices and itenables a manager of the devices to assign configuration parametersindividually only to the subset of the whole set of configuration datain order to provide a unique set of configuration data for a device.

Another aspect of the present invention provides a centrally manageddevice in which data for the device is stored and structured inaccordance with a common model of parameters related to the functioningand management of devices managed by a central management system. Themeans for communicating with the central management system is providedunder the control of the control means to control the sending ofmanagement data to the central management system.

In an embodiment of the present invention, the data comprises a set ofconfiguration parameters and a set of management parameters. Themanagement parameters are associated with respective configurationparameters and provide management information on the configurationparameters. Thus the management parameters comprise meta data for theconfiguration data.

In one embodiment the control means comprises a code module implementedby a processor in the device. The code module is downloadable from thecentral management system.

A further aspect of the present invention provides a devicedocumentation generation system method in which meta data for each ofthe parameters defining characteristics of a plurality of devices isstored. The meta data is stored in accordance with a common data modulefor the devices. Documentation can be input for association with metadata for respective parameters and documentation for a device can begenerated by incorporating the meta data into the documentation. In thisway, as the meta data is changed i.e. the management informationchanges, the documentation is automatically updated.

In one embodiment, the documentation can be input as segments associatedwith respective parameters defining the characteristics of the device.The document generation then includes aggregating the appropriatedocument segments for appropriate parameters relevant to the device.

In one embodiment the meta data includes an indication of the languageof the documentation to be generated for a device. The inputdocumentation is stored and can comprise documentation in more than onelanguage for a parameter. The documentation is then generated using thedocumentation in the language indicated by the indication in the metadata for the device.

A further aspect of the present invention provides a deviceconfiguration development system for developing control code fordevices. A code store stores a library of code stubs for providingdevice management functions. A data store stores metadata on deviceconfiguration parameters, wherein the meta data comprises managementinformation for the device configuration parameters. Meta data can beinput into the data store and code stubs can be determined for a deviceto provide the management functionality defined in the input meta datausing the library of code stubs in the code store.

Thus this aspect of the present invention enables a developer to merelyinput management information into the common database and receive inreturn code stubs for providing the management functionality to beincorporated within the developer's code for controlling the device.

A further aspect of the present invention provides a device managementsystem and method for providing information defining a managementinterface for devices to provide for local and central management.Device data structured in accordance with the common module for themanagement of devices is stored. Information defining a managementinterface for devices is input for storage in the device data. Thedevice data is output as a set of device data to provide a managementinterface for the central management of the set of devices and as devicedata for each data to provide the same management interface for thelocal management of each device.

A further aspect of the present invention provides a deviceconfiguration development system and method for developing and managingconfiguration and management information for devices. The requiredfunctionality of the devices is defined and desired attributes formanagement of the devices are entered. The entered attributes are storedas a central database for management of the devices and as a set of datain the devices for local management of the devices.

Any one of the aspects of the present invention described hereinabovecan be used in combination with any ones of the aspects of theinventions hereinabove.

Any aspect of the present invention described hereinabove can beimplemented in dedicated hardware, in a mixture of dedicated hardwareand programmable hardware or in solely programmable hardware. Thepresent invention can thus be embodied as programmable code forcontrolling a processor to carry out the processing steps. A carriermedium carrying the code is thus within the scope of the presentinvention. The carrier medium can either be a transient carrier mediumor a storage carrier medium. A transient carrier medium can comprise asignal such as an electrical, optical, microwave, radio frequency oracoustic signal carrying computer code. An example of a transientcarrier medium is a signal carrying computer code over the Internet (anInternet Protocol (IP) Network). The storage medium can comprise anyconventional storage medium such as a floppy disk, hard disk, CD ROM,tape device, or solid state memory device.

Embodiments of the present invention will now be described withreference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a hardware model used in accordancewith an embodiment of the present invention,

FIG. 2 is a schematic diagram of a software model used in an embodimentof the present invention,

FIGS. 3 a to 3 k are tables illustrating the data structure of thehardware model in a relational database in accordance with an embodimentof the present invention,

FIGS. 4 a to 4 e are tables illustrating the data structure of thesoftware model in a relational database in accordance with an embodimentof the present invention,

FIGS. 5 a to 5 d are tables illustrating the interfacing between thehardware model and the software module in a relational database inaccordance with an embodiment of the present invention,

FIG. 6 is a table providing information on configuration data,

FIG. 7 is a table providing the documentation information for theparameters in the tables,

FIG. 8 is a table giving information on the external form of attributesin the embodiment of the present invention,

FIGS. 9 a and 9 c are selected tables used for identifying userinterface selection options in accordance with an embodiment of thepresent invention,

FIG. 10 is a table of the configuration data,

FIG. 11 is a schematic diagram of a development system in accordancewith an embodiment of the present invention,

FIG. 12 is a flow diagram of the development process in accordance withan embodiment of the present invention,

FIG. 13 is a flow diagram showing the development and management of themanagement information used for documentation in accordance with anembodiment of the present invention,

FIG. 14 is a schematic diagram of a device management system inaccordance with an embodiment of the present invention,

FIG. 15 is a schematic diagram of the components of a device in whichthe components provide for central and local configuration andmanagement of the device,

FIG. 16 is a diagram showing the retrieval of management information,

FIG. 17 is a diagram illustrating retrieval of parameters,

FIG. 18 is a diagram illustrating the download of configuration data toconfigure the device,

FIG. 19 is a diagram illustrating the configuration of a device,

FIG. 20 is a diagram illustrating the implementation of a feature in adevice,

FIG. 21 is a diagram illustrating the retrieval of managementinformation using a command line interface,

FIG. 22 is a diagram illustrating the setting of a feature using thecommand line interface,

FIG. 23 is a diagram illustrating the interfacing to the meta data usinga command line interface, and

FIG. 24 is a schematic diagram of the use of the configuration andmanagement components as a ubiquitous interface to any device.

The present invention is built the premise of a common management model.The management model is common to:

-   1. The developer when developing the code for the device and the    development managers,-   2. The network manager (device manager) responsible for managing a    network of devices, and-   3. The devices that contain a set of the configuration and    management data appropriate for the device.

Thus during the development phase, the developer and the developmentmanager work on these same data which will end up on the devices and onthe networked device managing system.

The common management model used is based on a meta data model. The metadata model comprises a hardware model, a software model andrelationships therebetween. The model used and the data structure inaccordance with the model will now be described.

FIG. 1 schematically illustrates the hardware model. A hardware model,defines a hardware model for a product that can comprise a number ofchassis. Each chassis can have a number of slots into which can beplaced a number of cards. Each card can have a number of ports.

Thus this is a hardware model of a network device having communicationports. Thus for example, the port can comprise an ISDN port, a ATM port,or an ADSL port as an port instance. The card can identify thecapabilities of a card e.g, a ISDN card, a ATM card, or a ADSL card as acard instance. The slot identifies the type of slot provided in thechassis e.g. a ISA slot or a PCI slot as a slot instance. The chassisidentifies a chassis instance having a particular chassis serial number.The hardware model will also be given a name identifying that hardwaremodel as a hardware instance.

FIG. 2 is a schematic diagram of a software model. A software release ora software version all have a number of features, e.g. an IP (InternetProtocol) capability. Each feature will have components e.g. IPsys. Eachcomponent will have an attribute e.g. timeout.

Thus the hardware and software model define the characteristics of thesystem. Values for attributes can be set as configuration data in orderto define a configuration instance for the device. This comprises theconfiguration data table (FIG. 10) that will be described in more detailhereinafter.

FIGS. 3 a to 3 k illustrate the data structure that is a series ofrelational database tables for the hardware model in an embodiment ofthe present invention.

FIG. 3 a illustrates the port table. The port represents a physical portwill have a connection to another real world entity. Information will betransferred across the port into the device. There are many differenttypes of port and the type of port determines the type of connectionassociated with the port. A port is part of a card and a card cancontain zero or many ports and thus a port type can have more than oneinstance. It is possible to run multiple logical interfaces over asingle port. The set of logical interfaces available is determined by acombination of the port type and the software version running on thedevice.

The parameter PortOID defines a unique identifier for each port.BaseInterfaceNumber identifies a base number at which logical interfaceson this port will be based. Interfaces will be described in more detailhereinafter with reference to FIGS. 5 a to 5 d. Document_RES comprises apointer to the documentation text for this port. The documentation tablewill be described in more detail with reference to FIG. 7.

FIG. 3 b is a table for mapping ports to a card. Each card is uniquelyidentified together with each port. It is also possible for a port tohave more than one instance on a card.

FIG. 3 c is a diagram of the card table providing data for a card. Eachcard is uniquely identified by a parameter CardOID. Marketing productcode for the card is also identified as well as a hardware boardrevision. The parameter BaseInterfaceNumber indicates the base numberthe logical interfaces on the card will be based at. There is also apointer to the documentation text for the card. A card represents aphysical card that is inserted into a device and provides a certaincapability in the device. Most cards will contain additional physicalports for the device which will be used to interface the device forother devices.

FIG. 3 d illustrates the card to slot mapping table which provides thelink between the card table and slot table. This table simply providespointers between the slots and the cards.

FIG. 3 e illustrates the slot table providing data for each slot. A slotrepresents a physical slot that is present on a chassis. A slot is of aparticular type and this determines the set of cards that are compatiblewith the slot. There are can be zero or more slots available on achassis. Each slot is identified by a unique identifier and adescription is provided of the slot. A pointer to the documentation textfor each slot is also provided in the table.

FIG. 3 f illustrates the slot to chassis mapping table to link the slotsto the chassis. The table provides unique pointers between the slots andthe chassis. Each slot can have more than one instance i.e. there can bemore than one slot of the same type on the chassis.

FIG. 3 g illustrates the chassis table. The chassis represents thephysical chassis that can be inserted into a hardware model. The chassisis simply a carrier for slots into which cards can be inserted. Achassis is compatible with a particular model or set of hardware models.An example of a chassis will be a compact PCI chassis or a case for anISDN router. Each chassis is uniquely identified by information on themarketing product code and hardware board revision is provided in thetable. Also the unique pointer to the documentation text for the chassisis provided in the table.

FIG. 3 h illustrates the chassis to hardware model mapping table. Thismaps the chassis to a hardware model. The table uniquely identifies thehardware and each chassis linking to the hardware model. A chassis canhave more than one instance in the hardware model.

FIG. 3 i illustrates the hardware model table. A hardware modelrepresents an actual physical hardware model that is deployed by a nameduser. A model is simply a container for the chassis that will actuallycontain the hardware for the device. An actual hardware model could bean ISDN router or a cabinet rack that contains a specified set ofchassis. The hardware model table contains a unique identifier of eachhardware model together with the marketing product code for eachhardware model. Also a pointer to the documentation text for thehardware model is included in the table.

FIG. 3 j illustrates the hardware model to family mapping table thatmaps the links between a hardware model and a hardware product family.

FIG. 3 k illustrates the family table. A hardware model family isintended to represent a collection of hardware models that are part ofthe same marketing product group. Each family is given a uniqueidentifier together with a description of the product family. The tablealso contains a pointer to a documentation text for each product family.

It can thus be seen that FIGS. 3 a to 3 k provide a data structure toidentify the hardware characteristics of a device with links todocumentation for particular characteristics.

FIGS. 4 a to 4 e illustrate the tables forming the data structure of thesoftware model.

FIG. 4 a illustrates the attribute table that defines the attributecharacteristics. A software configuration attribute represents a singleconfigurable parameter that could potentially map to a particularstructure or memory location in the device. From a configurationmanagement point of view it is the values of the configurationattributes that must be stored to have a complete view of the parametersthat are configured in the device. Configuration parameters areversioned so that changes in their default values, ranges and labels canbe performed over the time. The history of an attribute can be kept sothat the evolution of a parameter can be followed in an audit. Thesoftware version is made up of a collection of configuration attributesthat describe the complete set of parameters configurable in thesoftware version. As can be seen in FIG. 4 a, an attribute is given aunique identifier together with a version number. Each attributeincludes a pointer to the component that holds the attributes. The typeof attribute is also identified. The type identifies the user interfacetype for the attribute. For example the attribute could be a SELECT typewhich means that it will be linked to a selector so that when theattribute is displayed, a drop down menu is displayed to allow theattribute value to be changed by selection from the menu. A userinterface label for the attribute as well as minimum and maximum valuesand a default value for the attribute are also contained in the table. Adisplay size on the user interface for the attribute and text thatshould be appended after the user interface representation for theattribute are also included in the table together with help text. Theparameter SelectorName identifies a selector name that can be used inthe user interface. This will be described in more detail hereinafter.The order of the attribute in the display is also identified by aparameter in the attribute table. The table further contains a pointerto the documentation text for the attribute.

Thus the attribute table contains meta data for an attribute. Anattribute can have a value which will be held by a configuration datatable as will be described in more detail with reference to FIG. 10.FIG. 4 a stores meta data which can be used for management and forproviding a management interface. The information regarding the userinterface can be used by user interface code to generate a managementuser interface which is standard and common whether the data is beingviewed centrally or at the device.

FIG. 4 b illustrates the component table. A software configurationcomponent acts as a view of configuration attributes. When generating aninterface such as a web interface for a particular component, a singleform can be created which displays all the attributes associated withthe component. It is possible for a configuration attribute associatedwith more than one configuration component. This allows for multipleviews of collections of attributes to be built up. Each component isgiven a unique identifier. Within the table each component has the nameof the parent feature to link to the parent feature. The type ofconfiguration component is indicated. The configuration component caneither be a system configuration component or an interface configurationcomponent. The concept of system and interface objects is based on theapproach by SNMP modelers defined in RFC 1213 MIB-II. Interface objectsrelate to interfaces and can be both physical e.g. ports and logicale.g. protocols such as PPP and X25. System objects are system wide e.g.protocols such as IP, SNMP or TCP or software applications. The maximumnumber of elements that can be stored by the configuration component isalso part of the configuration table and a user interface titled to theconfiguration component is stored. Further, there is a unique pointer tothe documentation text for the configuration component.

It can thus be seen that the component table provides all the necessaryinformation to provide a user interface comprising a single view of allof the attributes associated with the component and the user interfacetitle will appear on such a user interface.

FIG. 4 c illustrates the feature table. A software feature is a set ofrelated component definitions. The feature table contains a uniqueidentifier of the feature together with a short description of thefeature and a pointer to documentation text for the feature.

FIG. 4 d illustrates the software version table. The software versionrepresents all of the information that is relevant to the meta data ofthat particular software release for a device type. An entry in thistable represents an actual source code release from a device developmentteam. Each software version is given a unique identifier in the tableand its file name is identified. An identity tag which comprises astring which identifies the software version as it would appear in theembedded device is also contained within the software version table. Aversion number and user friendly description of the software version isfurther included in the table. The parameter ActivationMechanism definesthe mechanism that will be used in the device to activate the software.The parameter InterfaceStack determines the interfaces that areavailable for the software version to link the hardware and software aswill be described in detail hereinafter. The user interface provided inthis embodiment of the present invention is a web interface and thisrequires a web server. Thus the parameter WebVersionOID identifies theweb version which will accompany the software and be loaded on thedevice. The software version table also includes a pointer to thedocumentation text for the software version.

FIG. 4 e illustrates the attribute software mapping table which linksthe software versions and each attribute provided by the softwareversion.

FIGS. 5 a to 5 d illustrate the data tables for the interface modellinking the software and hardware models.

FIG. 5 a illustrates the interface table. The logical interfacerepresents the end of a logical connection over the device over aspecific protocol. A logical interface can allow other logicalinterfaces to run over it to form a containment tree. Each logicalinterface is given a unique identifier and description. The logicalinterface is also given a number at which logical interfaces of thattype are based on. Further, a unique pointer to documentation for theinterface is also contained in the interface table.

FIG. 5 b illustrates the interface stack table. This table illustratesthe nesting of logical interfaces in a management model. The interfacestack include a unique identifier of the management model that therelationship is part of. The lower and higher level interfaces areidentified and how many instances of the higher layer interface can runon top of the lower layer interface. The table also includes adescription of the relationship.

FIG. 5 c illustrates the component to interface mapping table. Thesemappings indicate a set of constraints on the relationships rather thanan actual assignment. For example an ISDN configuration object can berelated to an ISDN type interface but not to an Ethernet type interface.In other words the mapping data indicates the maximal set of allowedmappings.

FIG. 5 d illustrates the port to the interface mapping table in which aport is mapped to an interface.

Thus FIGS. 5 a to 5 d illustrate how ports and components can be mappedto interfaces that can be stacked. For example an interface can be anISDN logical interface. An ISDN logical interface can support theInternet Protocol (IP) and the point to point protocol (PPP). Thus thesoftware feature IP includes components such as IPsys and IP interface.Thus the interface stack can define the relationships between the portand the components in a stacked manner.

FIG. 6 illustrates the configuration information table. This table isnot part of the metadata or development data. This data is the actualdata or values for a configuration instance for a device. Aconfiguration is assigned a unique value that can identify the completeconfiguration of a device or a profile configuration that can be usedfor configuring a family of devices. Devices can be stand-alone devicesthat have been configured completely or profile devices that can beconfigured from a profile by the insertion of specific configurationparameters to distinguish a specific device configuration. Theconfiguration is given a name and the type of configuration isidentified i.e. whether it is a profile, a profiled device or a standalone device. Each configuration is given a serial number and forprofiled devices, the identification of the profile on which theprofiled device configuration is built is also stored in the table. Thetable further stores information on the current state of the device orprofile. The current state indicates whether the configuration is in apending state i.e. changes have been made, an accepted state where theconfiguration is available for use in a device, or active where theconfiguration has been used in a device. The parameter SwVersionOIDidentifies the version of the software to be assigned to the device. Thesoftware version has an attribute that identifies the software binaryimage that will be loaded on the device. WebVersionOID identifies theversion of the embedded web pages that will run in the device.HwModelOID identifies the hardware model for the device.

FIG. 7 illustrates the documentation table containing the documentationtext for devices. Each characteristic in the hardware and software modelwhich includes a unique documentation identifier links to documentationin the documentation table. There is also a language field to enable thelanguage of the documentation to be set.

FIG. 8 illustrates the external form table. This table defines theexternal form for attributes. The table identifies the attribute and theattribute version and gives an identifier for the external form to gowith the actual form name. The external form defines the data syntaxtransformation. For example it can define a command line interface (CLI)string for the attribute for use by a CLI module in an embedded systemin a device.

FIGS. 9 a, 9 b and 9 c illustrate selector tables to provide drop downmenus to allow a user to select parameters. Selector names are linksfrom other tables to define the appearance and utility of a userinterface.

FIG. 9 a illustrates a selector table that gives the name of a selectorand an identifier for the selector element. The user interface displayorder and label is contained within the selector table together with avalue that is represented. There is also a unique pointer to thedocumentation for the element. A selector element represents anindividual entry in an enumeration in a selector. Each selectorrepresents one entry from a possible list of entries.

FIG. 9 b illustrates a configuration selector table. A configurationselector represents an enumeration of values that can be set for aconfiguration command.

FIG. 9 c illustrates the software version selector table. This tableholds a unique identifier for each software version and identifies aselector parent and selector elements.

FIG. 10 illustrates a configuration data table. This data is not part ofthe metadata and it stores configuration data that comprises instancesof attributes that belong to a device configuration or a profileconfiguration. Each configuration is given a unique ID and eachconfiguration value is given a version number (VersionIx). The parameterInterfaceIx identifies which interface this attribute is associatedwith. The parameter ListIx enables more than one value for attributes.The attribute is identified using the parameter ConfigAttributeOID. Thevalue is assigned as FieldValue. The parameter IsPartOfQuickPageindicates whether this configuration instance is an attribute that canbe modified by a user to generate a profiled device configuration. Theattribute meta data is used to form part of a display termed “aQuickPage”. A QuickPage enables value (configuration parameters) to beinput by modifying default values to complete a profiled deviceconfiguration. The QuickPage comprises a user interface to allow a userto enter the values for attributes. If the configuration ID indicatesfrom the configuration information table (FIG. 6) that the configurationis a profile, then this flag indicates that the attribute is part of a“profiles QuickPage” definition and the FieldValue is the default valueto be used when creating a device based on the profile. The value canhowever be changed by a user using the QuickPage. If the configurationID identifies a profile device then this field indicates that theFieldValue contains the final value to be used for the attribute forthat device.

The use of these data tables as a common set of configuration andmanagement data will now be described.

FIG. 11 is a schematic diagram of a development system for thedevelopment and management of configuration data and management data fordevices. A development server 1 stores the data tables describedhereinabove in a database 2 under the control of a database manager 3.The table that are stored in the development system are the metadatatables since no specific configuration instance data is generated. Thegeneration of specific configuration instances is performed in thedevice manager and thus in the development system the configurationinformation table of FIG. 6 and the configuration data table of FIG. 10are not stored in the database 2. A user's module 4 provides a gatewayto the database for users and controls the type and level of access tothe data A web server 5 is provided to use server side scripting such asactive server page (ASP) code 6 or Java server page (JSP) code toprovide a web interface to certain users. The web server 5 uses the ASPto generate web pages using data from the database 2. The data comprisesthe configuration data giving the values for attributes and the metadata defining the way the configuration data should be displayed. Thedevelopment server 1 also includes a product release builder 7 forbuilding a software product for release. Developers code 8 and codestubs 9 are also provided for building of binary code included in theproduct by the product release builder 7. Thus the product releasebuilder 7 outputs a device management product 10. A documentationapplication 11 is provided for the generation of documentation for adevice using the documentation included in the meta data stored in thedatabase 2.

A developer's computer 20 in this embodiment is shown separately to thedevelopment server 1. The functionality can however be incorporatedwithin the development server 1. The developer's computer 20 includes adevelopment application 21 which can comprise a Java application runningon a Java Virtual Machine. The development application includes a codegenerator 22 to allow a developer to generate code to providefunctionality required of a device. A code stub generator 23 is alsoprovided for the automatic generation of code stubs 9 for managementpurposes. The user interface 24 is also provided to allow the developerto interface to the application. The development application 21 thusenables the developer to generate developer's code 8 and code stubs 9.The development application 21 interfaces via the user's module 4 to thedatabase manager 3 to gain access to the database 2 to thereby operateon the data structure as described hereinabove.

The administrator's computer 30 is illustrated in this embodiment asbeing separate to the development server 1. It can however beincorporated within the development server 1. Within the administrator'scomputer 30 a development application 31 is operated by theadministrator to enable the administrator to access the database via theuser's module 4 and database manager 3. Also the development application31 controls the product release builder 7 to control the release of thedevice management product 10.

Other users of the system can gain access to the database 2 using thecomputer 40 hosting a web browser 41 to gain access via the web server5, the user's module 4 and the database manager 3.

Thus the development system illustrated in FIG. 4 can be used bysoftware developers using the developer's computer 20 to develop codefor implementation on devices.

Also an administrator can control the information being entered into thedatabase 2 to provide a management function to manage the configurationand management data contained within the database 2 and to control therelease of a device management product 10. Other persons can gain accessto the database 2 to contribute to the development of the data in thedatabase. For example, a documenter can use the computer 40 in order toaccess the database 2 in order to add information into the documentationtable as illustrated in FIG. 7. The access provided to the documentercan be controlled by the user's module 4.

A translator can gain access to the documentation in the documentationtable as illustrated in FIG. 7 in order to input translations ofdocumentation where necessary. Once again the functionality madeavailable to the translator can be controlled by the user's module 4.

The steps performed during the development of a device will nowdescribed with reference to the flow diagram of FIG. 12.

Initially market research is carried out in order to determine productrequirements (step S1). This results in a product definition (step S2)and a functional specification is drawn up (step S3). Following thishardware and software is designed to provide the functions (step S4 andS5). These steps can be carried out iteratively to arrive at thenecessary hardware and software to perform the functions. During thedesign of the software, a developer can use a developer's application toaccess the database 2. The developer enters data describing hardware andsoftware (step S7).

This can be achieved by selecting a previous hardware model in thedatabase 2 (step S7 a) and selecting a previous software model (step S7b) meta data for the previous model is copied and a new entry made inthe database 2. The data can then be modified by the developer to modifythe entries in the database to specify new hardware or softwarecharacteristics (step S7 c). Thus in step S8 data is entered into thedatabase. Code stubs to provide the management functions can then beautomatically generated (step S9) and under the control of theadministrator using the administrator's computer 30, the developer'scode 8 and the code stubs 9 can be taken in by the product releasebuilder 7 to build a management device product 10 (step S10). Theproduct includes:

-   -   a. an installation application for installing the code onto a        network management system,    -   b. configuration data and meta data for a set of products to be        managed by the network management system, and    -   c. binary code for the devices to be managed (performed by        combining the developer's code 8 and the code stubs 9), which        includes metadata for the management and configuration of the        device.

The software product is thus the code required for a new softwarerelease for a device and it includes meta data for the configuration andmanagement of the device by a network (device) manager.

The network management code is a standard code that utilizes themetadata for managing and configuring devices and determined by thesoftware release. The network management code can thus be providedseparately or combined with the software release product for a device toallow the management and configuration of the device over a network.

FIG. 13 is a flow diagram illustrating the process of managing anddeveloping the configuration and management data in the database 2. Instep S20 a user uses the computer 40 to access the web server 5 and logsin. The user's module 4 determines the role to be performed by the user(step S21). If a user is a documenter, the user can access undocumentedfeatures that are presented as a web page (step S22). The user is thusable to enter documentation for a particular features or characteristicso the software or hardware. If changes are made in the database (stepS23), the database is updated in step S24 and the user can then log outin step S25.

If it is determined by the user's module 4 that the user is a reviewer,they are presented with a web page of unreviewed features (step S26) thereviewer can thus review the features and make any changes they feel itsnecessary. If the user's module 4 determines the user is a translator,untranslated features are presented to the user as a web page (stepS27). The translator can thus enter translations as necessary.

It is thus apparent to the skilled person in the art that to arrive atthe development process a common database is used by the developers andmanagers in order to provide configuration and management data for thedevices. When the development process is complete, an administrator cancause the product release builder 7 to generate a management deviceproduct for the management of a set of devices. A device managementproduct 10 can then be installed in a device management system to managenetworked devices.

FIG. 14 is a schematic diagram of a network device management system inaccordance with an embodiment of the present invention. When the devicemanagement product 10 is stored in a computer system, the device manager50 illustrated in FIG. 14 is generated. The device manager 50 isconnected over a network 60 to networked devices 70, 71, 72 and 73. Thenetwork preferably comprises an Internet Protocol (IP) network. Withinthe device manager there is a database 51 storing a copy of the datastored in the database 2 within the development system 1. The metadatatables are copied and also configuration instance tables (FIGS. 6 and10) are set up to store configuration instances for devices. A databasemanager 52 controls access to the database 51. A device code store 53stores binary code for each of the devices 70, 71, 72 and 73. A deviceconfigurator 54 (also termed a VAMP client/server) provides theconnection over the network 60 to the devices 70, 71, 72 and 73. Thusthe device configurator 54 can download the code stored in the devicecode store 53 to the devices 70, 71, 72 and 73 in order to provide thecode for controlling the devices to provide the management function. Thedevice configurator 54 can also access the database 51 via the databasemanager 52 in order to download a copy of configuration and managementdata to the network devices 70, 71, 72 and 73. The devices 70, 71, 72and 73 need only store the configuration and management data relevant tothe respective device. It is however configuration and management datathat has been derived from the common data structure in databases 2 and51 in the development system I and the device manager 50 respectively.

In this embodiment the device configurator 54 acts as both the webserver and web client since the protocol used for communication over thenetwork 60 to the devices 70, 71, 72 and 73 is preferable the hypertexttransfer protocol (HTTP).

The device manager 50 also includes a configuration generator 55 forgenerating a complete set of configuration data i.e. the deviceconfiguration from a profile configuration. This enables the operator ofthe device manager 50 to configure multiple devices using a singleprofile. When a profile configuration is available, the user of thedevice manager 50 can use the configuration generator to select theprofile and use it to generate a profiled device by entering parameters.This can be done by using a user interface termed a “Quick Page” toallow a user to enter the necessary parameters to distinguish theindividual device. The Quick Page allows the default values of certainattributes in a profile configuration to be modified by the manager toprovide the configuration comprising the profile device. The profiledevice configuration can then be downloaded to configure a device 70,71, 72 or 73 by the device configurator 54. The manager can define newprofile configurations by defining attributes which are part of theQuickPage.

FIG. 15 schematically illustrates modules in the device to provide forlocal and central management of the device.

A platform application 100 to be configured and managed is interfacedvia glue 101, 102 and 103 comprising code to an interprocesscommunication module 104 for communication with a portable communicationmodule 105. A portable communication module 105 interfaces to BSD(Berkeley Distribution System) sockets. Within the device thecommunication protocol stack comprises Internet Protocol (IP) 106,Transmission Control Protocol (TCP) 107, and Unigram Data Protocol (UDP)108 and a serial port 109 is provided to interface to the BSD sockets110. The portable module 105 is the code that is common to all devices.Within the module 105 a web server 111, a TELNET server 112 and a serialinterface 113 are provided. The device can communicate via HTTP using aVAMP engine 114. It can also communicate using the traditional commandline interface 115 via the TELNET server 112 or serial interface 113. Atthe heart of the module 115 is a management request broker 116 thatcontains configuration data and logic and meta data for theconfiguration and management of the device. A configurationinstrumentation broker 119 is provided in conjunction with theconfiguration glue 111 for communication to the platform applicationsoftware 100. A Simple Network Management Protocol (SNMP)instrumentation broker 120 is provided in conjunction with the glue 102for communication of instructions to or from the platform applicationsoftware 100. The SNMP instrumentation broker 120 is provided to allowintegration with SNMP agents running in the device. An eventinstrumentation broker 121 is provided in conjunction with event glue103 to communicate events from the application software 100 into theembedded framework event management system.

An event system 122 monitors events and a performance monitor 123monitors performance statistics. This enable the provision of event andstatistic management information via the VAMP engine 114 in a managementinterface as a web page. A simple mail transfer protocol (SMTP) client124 is provided to enable e-mail communication with the device.

Embedded web data 125 stores web information for the construction of webpage interfaces as an interface to the device. A scripting engine 126provides for scripting and a scheduler 127 schedules certain actionsunder the control of timer services 128.

FIG. 16 illustrates the operation of the device acting as a web serverto display management information in the form of a web page for afeature x.

The HTTP server 111 receives an HTTP get request for the web page formanagement information on feature x via the TCP/IP stack 106 and 107from a web browser loaded on a computer 170. Computer 170 comprises cancomprise any web enabled computer.

The request is passed on to a VAMP engine 114 to provide the managementfunctionality. Embedded web information 125 is used by the VAMP engine114 to construct the hypertext transfer mark up language (HTML) i.e. theweb page to be returned. The VAMP engine 114 also requests informationfrom the management request broker 116. The management request brokerreturns meta data which is used by the VAMP engine 114 to construct theweb page. Thus the meta data stored by the management request broker 116controls the user interface by configuring the form of the web page. Themeta data can control the order in which items appear, the text toappear after items, and the language used. The management request broker116 also returns configuration data which comprises the actual valuesfor parameters. The web page constructed by the VAMP engine 114 is thenreturned to the computer 170 for display as a web page.

In this embodiment illustrated in FIG. 16, management request broker 116is able to respond to the request for management information from theVAMP engine 114 using configuration data stored within the managementrequest broker 116.

FIG. 17 illustrates an example where the management information requiredin the HTTP request from the computer 170 is not all contained withinthe configuration data within the management request broker 116. Forexample, the information required could include status data. In thisembodiment the HTTP server 111 receives the request and passes to VAMPengine 114. The VAMP engine uses the meta data from the managementrequest broker 116 to determine whether the information requested ispresent within the configuration data. If, using the meta data, it doesidentify that the attributes requested are present in the configurationdata but must be obtained from the hardware platform on which the codemodule 1 15 is being implemented, a callback is invoked by themanagement request broker 116 through the configuration instrumentationbroker 117, the interprocess communication 104 and the configurationglue 111 to the platform application software 100. The requestedattribute information is returned to the management request programme116 and passed on to the VAMP engine 114 for inclusion within the webpage as described with reference to FIG. 16.

Thus in the embodiments of FIG. 16 and FIG. 17, a web page interface isprovided for management information thus allowing local or remote accessto management information on the network device.

In the embodiments illustrated in FIGS. 16 and 17, the scripting engine136 stores code for the dynamic generation of web pages. However, it ispossible also for static embedded web pages to be used.

FIG. 18 is a diagram of the operation of the device when performing anauto provisioning function. When the device is in an initial factoryconfigured state, the device executes a script within the scriptingengine 136 which causes the VAMP engine 114 to control HTTP server 111to generate and an HTTP get request to the VAMP server 54 in the devicemanager 50 for configuration and management information. The requestedinformation is returned by the VAMP server 54 in the device manager 50and is received at the VAMP engine 114 via the HTTP server 111. The VAMPengine 114 then stores the retrieved configuration and management datawithin the management request broker 116. It can also store downloadedweb page data in the embedded web store 125. Thus in this way the devicecan be initially configured automatically.

FIG. 19 is a diagram illustrating the modification of parameters underthe control of the device configurator acting as a VAMP client 54 withinthe device manager 50. The VAMP client sends an HTTP request withattributes that are received in the VAMP engine 114 via HTTP server 111.The management request broker 116 invokes call backs into theapplication software 100 in order to attempt to modify an attribute inthe platform application software 100. A response is then returned tothe VAMP client 74 within the device manager 50 via the VAMP engine 114.The state of the object is then stored by the management request broker116. Thus the management data is only updated if the request wassuccessful e.g. if the request was to disable a circuit but the circuitwas busy, the device will not action the request and the management datamust reflect this.

The VAMP client 54 within the device manager 50 can also retrieveconfiguration data from the management request broker without performingthe modification of the attributes in a similar manner to that describedwith reference to FIG. 19 except that no callback is invoked into theplatform application software 100. Instead the configuration data isused to return the requested attributes as a HTTP response to the VAMPclient 54 within the device manager 50.

FIG. 20 illustrates the process of implementing or registering a featurein the device. The management request broker 116 includes meta data andconfiguration data for the feature. The configuration instrumentationbroker 119 initiates the callbacks for the registration process in orderto pass the necessary attributes. Thus using callbacks, theimplementation of feature X can be configured in the device.

FIG. 21 illustrates the provision of a command line interface capabilitywithin the device to allow the fetching of attributes. A command lineinterface 115 is provided to enable a TELNET session to be used forcommunication with the device. In this embodiment a computer 170establishes a TELNET session over the TCP/IP stack 106 and 107 with theTELNET server 112. The TELNET server 112 passes on the command lineinput to the command line interface 115. The command line interface 115interacts with the management request broker 116 in order to determineif necessary responses can be provided from the configuration data usingthe meta data. The command line interface 115 then generates a textresponse that is passed by the TELNET server 112 as a response in theTELNET session to the computer 170.

FIG. 22 illustrates the use of the command line interface 115 to modifyattributes in the platform application software 100. A TELNET session isestablished by a computer 170 with the TELNET server 112 over the TCP/IPstack 106 and 107. The input attribute setting request is received bythe command line interface 116 which uses the meta data to determinewhether the response can be fulfilled by the configuration data. In thiscase it could not and a callback is invoked by the management requestbroker 116 through the configuration instrumentation broker 119 to theplatform application software 100 in order to pass on the attributemodification. The response is received to confirm the modification andthe command line interface 115 responds with an appropriate responsethat is passed by the TELNET server 112 to the computer 170.

FIG. 23 illustrates the use of the command line interface for retrievingmanagement information i.e. on-line help for users of the command lineinterface. A user types in a component name e.g. set feature X, butcannot remember the attribute. A request for information on feature X issent as a command line instruction over a TELNET session on the computer170 via the TELNET server 112 to the command line interface 115. Thecommand line interface 115 retrieves the necessary information from metadata within the management request broker 116 in order to return theinformation. In this case the attributes for a component are thereturned information. A user can select one to complete the command.

FIG. 24 is a schematic diagram illustrating the flexibility of the codemodule 115. This can be installed in any network device 150 to providethe management and configuration function. The management andconfiguration function can be provided by connecting a computer 170using the web browser over the network connection 160 to interface tothe code module 105. The code module 105 can either be loaded into thedevice 150 or can be provided on a separate physical device e.g. aninternal card, or an external module.

This enables the provision of a web interface for existing products,providing a management and configuration function that can easily beaccessed as web page data.

Although the present invention has been described hereinabove withreference to specific embodiments, it will be apparent to a skilledperson in the art that modifications lie within the spirit and scope ofthe present invention.

The present invention is application to any device that can be managedcentrally such as a networked device.

The management data can comprise any function or parameters that requiremonitoring or control. The management parameters can include statistics,notifications from the devices, device performance parameters, and/ordevice status parameters.

1. A device information development system for developing and managingconfiguration and/or management information for devices, the systemcomprising: data storage means storing device data structured inaccordance with a common model of parameters related to theconfiguration and/or management of the devices; developer interfacemeans for allowing a software developer to develop software forconfiguring and/or managing devices and to enter device data into thedata storage means in accordance with the common model; software productbuilding means for building a device configuration and/or managementsoftware product for configuring and/or managing at least one device,the software product building means being adapted to build the softwareproduct by reading data for at least one device from the data storagemeans structured in accordance with the common model for use by devicemanagement and control software to control a processing apparatus toconfigure and/or manage the devices using the data for the devicesincluded in the product and to provide the data for a device to thedevice to allow local configuration and/or management at the device; andsoftware storage means storing device management and control softwarefor at least one of configuring and managing a device, wherein saidsoftware product building means is adapted to build the software productto include the device management and control software.
 2. A deviceinformation development system according to claim 1, wherein the devicescomprise network devices and the common model is a model of parametersrelated to the configuration and/or management of the network devices.3. A device information development system according to claim 1, whereinthe parameters related to the configuration and/or management of thedevices are suitable for central remote management of the devices andlocal management of each device.
 4. A device information developmentsystem according to claim 1, wherein the common model of parametersrelated to the configuration and/or management of the devices comprisesa model of hardware characteristics, software characteristics andrelationships therebetween.
 5. A device information development systemaccording to claim 1, wherein said device data comprises configurationdata and metadata, the metadata comprising management information forthe configuration data and for the device.
 6. A device informationdevelopment system according to claim 1, wherein the device dataincludes interface data defining the configuration of a user interfaceto the device data.
 7. A device information development system accordingto claim 6, wherein the interface data defines the configuration of eachelement of a user interface related to the display and/or input of aconfiguration parameter and/or management parameter.
 8. A deviceinformation development system according to claim 6, wherein theinterface data defines a management interface for configuring and/ormanaging the device and/or the device data.
 9. A device informationdevelopment system according to claim 6, including user interface meansfor providing an interface to a user using the interface data. 10.device information development system according to claim 9, wherein theuser interface means comprises a web server means for providing the userinterface as a web page.
 11. A device information development systemaccording to claim 1, wherein the developer interface means is adaptedto allow a developer to enter device data for a new device by copyingdevice data for another device and modifying the device data.
 12. Adevice information development system according to claim 1, wherein thedeveloper interface means is adapted to generate code stubs formanagement functionality from the device data for combination withsoftware provided by the software developer to control the device todevelop the software for configuring and/or managing the devices.
 13. Adevice information development system according to claim 1, wherein thedatabase storage means comprises a relational database storage means.14. A device information development system according to claim 1,wherein the common model is an object model comprised of hardwareobjects, software object, and interface objects linking the hardware andsoftware objects.
 15. A device information development system accordingto claim 1, including documentation storage means for storingdocumentation segments associated with respective parameters of thecommon model, and documentation input means to allow the input ofdocumentation segments for association with respective parameters of thecommon model.
 16. A device information development system according toclaim 15, including documentation generation means for generatingdocumentation for a device by combining the stored document segments forparameters related to the configuration and/or management provided forthe device.
 17. A device information development system according toclaim 1, wherein the common model includes a parameter to identify aconfigured device having configuration data for all configurationparameters, and a configuration profile for which some configurationdata can be input to complete or modify the configuration data for adevice.
 18. A device information development system according to claim17, wherein the common model includes a parameter to identify aconfigured device having some configuration data entered by a user andsome configuration data provided from the partial configuration.
 19. Adevice information development system according to claim 1, comprising aprocessing system, wherein the data storage means comprises a relationaldatabase, the developer interface means comprises a developer computerapplication implemented on the processing system, the software storagemeans comprises a storage device, and the software product buildingmeans comprises a software builder computer application implemented onthe processing system.
 20. A device information development method fordeveloping and/or managing configuration and/or management informationfor devices, the method comprising: providing a database storing devicedata structured in accordance with a common model of parameters relatedto the configuration and/or management of the devices; entering devicedata into the database in accordance with the common model when asoftware developer develops software for configuring and/or managingdevices; and building a device configuration and/or management softwareproduct for use in the configuration and/or management of at least onedevice by including in the software product the data for a set ofdevices from the database store structured in accordance with the commonmodel in the database for use by device management and control softwareto control a processing apparatus to configure and/or manage the devicesusing the data for at least one device included in the product and toprovide the data for a device to the device to allow local configurationand/or management at the device, wherein device management and controlsoftware is built into at least one of the device configuration andmanagement software product.
 21. A device information development methodaccording to claim 20, wherein the devices comprise network devices andthe common model is a model of parameters related to the configurationand/or management of the network devices.
 22. A device informationdevelopment method according to claim 20, wherein the parameters relatedto the configuration and/or management of the devices are suitable forcentral remote management of the devices and local management of eachdevice.
 23. A device information development method according to claim20, wherein the common model of parameters related to the configurationand/or management of the devices comprises a model of hardwarecharacteristics, software characteristics and relationshipstherebetween.
 24. A device information development method according toclaim 20, wherein said device data comprises configuration data andmetadata, the metadata comprising management information for theconfiguration data and for the device.
 25. A device informationdevelopment method according to claim 20, wherein the device dataincludes interface data defining the configuration of a user interfaceto the device data.
 26. A device information development methodaccording to claim 25, wherein the interface data defines theconfiguration of each element of a user interface related to the displayand/or input of a configuration parameter and/or management parameter.27. A device information development method according to claim 25,wherein the interface data defines a management interface forconfiguring and/or managing the device and/or the device data.
 28. Adevice information development method according to claim 25, includinggenerating an interface to a user using the interface data.
 29. A deviceinformation development method according to claim 28, wherein the userinterface is generated as a web page.
 30. A device informationdevelopment method according to claim 20, wherein device data for a newdevice is entered by copying device data for another device andmodifying the device data.
 31. A device information development methodaccording to claim 20, including generate code stubs for managementfunctionality from the device data for combination with softwareprovided by the software developer to control the device to develop thesoftware for configuring and/or managing the devices.
 32. A deviceinformation development method according to any one of claims 20 to 31wherein the database comprises a relational database.
 33. A deviceinformation development method according to claim 20, wherein the commonmodel is an object model comprised of hardware objects, software object,and interface objects linking the hardware and software objects.
 34. Adevice information development method according to claim 20, includinginputting and storing documentation segments associated with respectiveparameters of the common model.
 35. A device information developmentmethod according to claim 34, including generating documentation for adevice by combining the stored document segments for parameters relatedto the configuration and management provided for the device.
 36. Adevice information development method according to claim 20, wherein thecommon model includes a parameter to identify a configured device havingconfiguration data for all configuration parameters, and a configurationprofile for which some configuration data can be entered to complete ormodify the configuration data for a device.
 37. A device informationdevelopment method according to claim 36, wherein the common modelincludes a parameter to identify a configured device having someconfiguration data entered by a user and some configuration dataprovided from the partial configuration.
 38. A storage medium storingcomputer readable code for controlling a computer to developing and/ormanaging configuration and/or management information for devices, thestorage medium storing code comprising: code to provide a databasestoring device data structured in accordance with a common model ofparameters related to the configuration and/or management of thedevices; code to enter device data into the database in accordance withthe common model when a software developer develops software forconfiguring and/or managing devices; and code to build a deviceconfiguration and/or management software product for use in theconfiguration and/or management of at least one device by including inthe software product the data for a set of devices from the databasestore structured in accordance with the common model in the database foruse by device management and control software to control a processingapparatus to configure and/or manage the devices using the data for atleast one device included in the product and to provide the data for adevice to the device to allow local configuration and/or management atthe device, wherein device management and control software is built intothe device configuration and/or management software product.
 39. Adevice information development computer system for developing andmanaging configuration and/or management information for devices, thecomputer system comprising: a data store to store device data structuredin accordance with a common model of parameters related to theconfiguration and/or management of the devices; a processor; interfacecode to operate on the processor to generate a developer interface toallow a software developer to develop software for configuring and/ormanaging devices and to enter device data into the data storage means inaccordance with the common model; software product building code tooperate on the processor to build a device configuration and/ormanagement software product for configuring and/or managing at least onedevice, the software product building code being coded to build thesoftware product by reading data for at least one device from the datastorage means structured in accordance with the common model for use bydevice management and control software to control a processing apparatusto configure and/or manage the devices using the data for the devicesincluded in the product and to provide the data for a device to thedevice to allow local configuration and/or management at the device; anda software store to store device management and control software forconfiguring and/or managing a device, wherein said software productbuilding code is coded to build the software product to include thedevice management and control software.
 40. A device informationdevelopment computer system according to claim 39, wherein the devicescomprise network devices and the common model is a model of parametersrelated to the configuration and/or management of the network devices.41. A device information development computer system according to claim39, wherein the parameters related to the configuration and/ormanagement of the devices are suitable for central remote management ofthe devices and local management of each device.
 42. A deviceinformation development computer system according to claim 39, whereinthe common model of parameters related to the configuration and/ormanagement of the devices comprises a model of hardware characteristics,software characteristics and relationships therebetween.
 43. A deviceinformation development computer system according to claim 39, whereinsaid device data comprises configuration data and metadata, the metadatacomprising management information for the configuration data and for thedevice.
 44. A device information development computer system accordingto claim 39, wherein the device data includes interface data definingthe configuration of a user interface to the device data.
 45. A deviceinformation development computer system according to claim 44, whereinthe interface data defines the configuration of each element of a userinterface related to the display and/or input of a configurationparameter and/or management parameter.
 46. A device informationdevelopment computer system according to claim 44, wherein the interfacedata defines a management interface for configuring and/or managing thedevice and/or the device data.
 47. A device information developmentcomputer system according to claim 44, including a user interface forproviding an interface to a user using the interface data.
 48. deviceinformation development computer system according to claim 47, whereinthe user interface comprises a web server for providing the userinterface as a web page.
 49. A device information development computersystem according to claim 39, wherein the developer interface is codedto allow a developer to enter device data for a new device by copyingdevice data for another device and modifying the device data.
 50. Adevice information development computer system according to claim 39,wherein the developer interface is coded to generate code stubs formanagement functionality from the device data for combination withsoftware provided by the software developer to control the device todevelop the software for configuring and/or managing the devices.
 51. Adevice information development computer system according to claim 39,wherein the database store comprises a relational database store.
 52. Adevice information development computer system according to claim 39,wherein the common model is an object model comprised of hardwareobjects, software object, and interface objects linking the hardware andsoftware objects.
 53. A device information development computer systemaccording to claim 39, including a documentation store for storingdocumentation segments associated with respective parameters of thecommon model, and a documentation input device to allow the input ofdocumentation segments for association with respective parameters of thecommon model.
 54. A device information development computer systemaccording to claim 53, including documentation generation code forgenerating documentation for a device by combining the stored documentsegments for parameters related to the configuration and/or managementprovided for the device.
 55. A device information development computersystem according to claim 39, wherein the common model includes aparameter to identify a configured device having configuration data forall configuration parameters, and a configuration profile for which someconfiguration data can be input to complete or modify the configurationdata for a device.
 56. A device information development computer systemaccording to claim 55, wherein the common model includes a parameter toidentify a configured device having some configuration data entered by auser and some configuration data provided from the partialconfiguration.